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A system and method are provided for shar- 
ing data among a plurality of users via an intermit- 
tently accessed network. Included are a plurality 
of personal digital assistants, or PDA's (102), each 
suitable for storing a plurality of personal data sets 
thereon. Also provided is a server (104) for syn- 
chronizing a plurality of server data sets stored 
thereon with the personal data sets stored on the 
PDA's (102). A plurality of client computers are 
included for providing a communication link be- 
tween the PDA's and the server. Each commu- 
nication link is suitable for obtaining the persona] 
data sets of one PDA (102) on another PDA (102), 
thereby synchronizing the personal data sets be- 
tween different PDA's. In the absence of com- 
munication between the client computer (106) and 
the server (104), the communication link is further 
suitable for interfacing local memory of the cor- 
responding client computer (106) to synchronize a 
plurality of local data sets stored thereon with the 
personal data sets during synchronization. 
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System and Method for Synchronizing Data Among 
a Plurality of Users Via an Intermittently Accessed 

Network 

5 

FIELD OF THE INVENTION 

The present invention relates generally to personal digital assistants and, more particularly, to 
10 a system and method for synchronizing data over an intermittently accessed network. 

Background of the Invention 

15 Personal digital assistants, or PDA's, are commonly known hand-held computers that can 

be used to store various personal information including, but not limited to contact information, 
calendar information, etc. Such information can be downloaded from other computer systems, or 
can be inputted by way of a stylus and pressure sensitive screen of the PDA. Examples of PDA's 
are the Palm™ computer of 3Com Corporation, and Microsoft CE™ computers which are each 

20 available from a variety of vendors. 

Users of PDA's commonly do not rely solely on such units for storing important 
information. For example, full-size desktop computers are also used to store information during 
the course of other activities such as receiving and responding to electronic mail. This tends to 
25 lead to the generation of separate and discrete sets of information on both the PDA and desktop 

computer. Of course, maintaining multiple sets of information is undesirable due to obvious 
- ^ organization problems. 

To overcome this difficulty, information on a desktop computer is often "synchronized" 
30 with information on a PDA. In other words, any new information in the form of additions, 

deletions, and/or changes that exists on either the desktop computer or the PDA is reflected on 
both. By frequently synchronizing data between the desktop computer and the PDA, a user is 
ensured to have one set of completely updated information which leads to increased organization. 

1 
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One issue that is not fully addressed in prior art PDA's is synchronizing data between 
PDA's of different users. While the PDA of a first user may properly reflect the contact 
information of a person, i.e. John Doe, a second user may have John Doe's previous, incorrect 
5 contact information, thereby reflecting a lack of synchronization. Moreover, many complications 
can arise due to conflicting scheduled events and meetings. For example, calendar software of 
the Palm™ PDA only allows a single calendar to be used. 

Such lack of organization is primarily caused by the lack of shared information among 
10 PDA's of different users. Up to now, focus has been only on promoting organization of a single 
user by way of synchronization between a PDA, a desktop computer, and a remote server. 

There is thus a need for a system and method for synchronizing data between a plurality of 
different PDA's to promote organization among multiple different users. 

15 

Disclosure of the Invention 



A system and method are provided for sharing data among a plurality of users via an 
intermittently accessed network. Included are a plurality of personal digital assistants, or PDA's, 
each suitable for storing a plurality of personal data sets thereon. Also provided is a server for 
synchronizing a plurality of server data sets stored thereon with the personal data sets stored on 
the PDA's. A plurality of client computers are included for providing a communication link 
between the PDA's and the server. Each communication link is suitable for obtaining the 
personal data set of one PDA on another PDA, thereby synchronizing the personal data sets 
between different PDA's. In the absence of communication between the client computer and the 
server, the communication link is further suitable for interfacing local memory of the 
corresponding client computer to synchronize a plurality of local data sets stored thereon with the 
personal data sets during synchronization. 

In another embodiment, the types of personal data that may be stored on the PDA include 
contact and calendar information. During synchronization, both the contact information and 
calendar information may be exchanged between different PDA's. For example, contact information 
may be updated on multiple different PDA's, calendar information of a plurality of PDA's may be 

2 
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synchronized and conflicts may be addressed, and/or calendar information of a plurality of users may 
be stored and updated on each PDA. 



In yet another embodiment, the foregoing synchronization is facilitated by including 
separate identification codes for data stored on the PDA's and the server. While the server 
utilizes a set of server identification codes for tracking all of the information stored therein, each 
of the PDA's employs a unique set of personal identification codes for tracking all of the 
information stored in the PDA. The mapping, or correlation, between the personal and server 
identification codes may be stored in either the PDA's, the server, or a computer in which the 
communication link resides. In use, such mapping is critical during the synchronization of the 
data. 

In still yet another embodiment, the synchronization of the personal data of different 
PDA's only occurs on personal data specifically marked to be shared. By requiring the personal 
data to be marked as shared, privacy concerns are addressed and the user is granted selectivity 
with respect to who receives personal data. 

In yet another embodiment, conflicts between shared personal data are addressed with 
various methods. It should be noted that a conflict occurs when particular personal data of a first 
PDA is synchronized with the server data before similar shared personal data of a second PDA is 
synchronized with the server data. 

In order to deal with such conflicts, the present invention provides a resolution by replicating 
the particular conflicted personal data as a separate file. In the alternative, the conflict may be 
resolved by synchronizing the particular personal data of the second PDA with the server data, 
thereby overriding the personal data of the first PDA. In still yet another embodiment, the conflict 
may be resolved by not synchronizing the particular personal data of the second PDA with the server 
data, thereby being overridden by the personal data of the first PDA. Finally, the conflict may be 
resolved by marking the particular personal data of the second PDA to be altered by a user via a user 
interface. 

These and other advantages of the present invention will become apparent upon reading the 
following detailed description and studying the various figures of the drawings. 

3 
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Brief Description of the Drawings 

5 The foregoing and other objects, aspects, and advantages are better understood from the 

following detailed description of a preferred embodiment of the invention with reference to the 
drawings, in which: 

Figure 1 is a general diagram of the interconnection between a server, a plurality of personal 
10 digital assistants, and a plurality of client computers in accordance with one embodiment of the 
present invention; 

Figure 2 is a block diagram of an exemplary component configuration for the client 
computers of Figure 1 ; 

15 

Figure 3 is a more detailed illustration of the interconnection of the various components 
shown in Figure 1 ; 

Figure 4 is a block diagram depicting the conduit controller and the client messenger of the 
20 conduit in accordance with one embodiment of the present invention; 

Figure 5 is a general flowchart delineating the operations carried out by the conduit controller 
of the conduit shown in Figure 4 when handling contact information; 

25 Figure 6 is a specific flowchart illustrating the details associated with one of the operations of 

the conduit controller of the conduit shown in Figure 5; 

Figure 7 is a specific flowchart illustrating the details associated with one of the operations of 
the conduit controller of the conduit shown in Figure 5; 

30 

Figure 8 is a specific flowchart illustrating the details associated with one of the operations of 
the conduit controller of the conduit shown in Figure 5; 

4 
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Figure 9 is a specific flowchart illustrating the details associated with one of the operations of 
the conduit controller of the conduit shown in Figure 8; 

Figure 10 is a general flowchart delineating the operations carried out by the channel conduit 
5 of the conduit shown in Figure 4 when handling calendar information; 

Figure 1 1 is a general flowchart delineating the data structure and operations carried out by 
the server shown in Figures 1 and 3; 

10 Figure 12 is a specific flowchart illustrating the details associated with one of the operations 

of the server shown in Figure 1 1 ; 

Figure 13 is a specific flowchart illustrating the details associated with the operation of the 
client messenger during at least one of the operations of the conduit controller of the conduit shown 
15 in Figures 5 and 6; 

Figure 14 is a specific flowchart illustrating the details associated with the operation of the 
client messenger during at least one of the operations of the conduit controller of the conduit shown 
in Figures 5 and 6; . , ■ 

20 

Figure 15 is a specific flowchart illustrating the details associated with the operation of the 
client messenger during one of the operations shown in Figures 9 and 10; 

Figure 16 is a detailed flowchart illustrating one of the operations of the client messenger 
25 shown in Figure 15; 

. Figure 17 is a detailed flowchart illustrating one of the operations of the client messenger 
shown in Figure 1 6; 

30 Figure 18 is a detailed flowchart illustrating one of the operations of the client messenger 

shown in Figure 16; and 
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Figure 19 is a detailed flowchart illustrating one of the operations of the client messenger 
shown in Figure 16. 

Description of the Preferred Embodiments 

With reference to Figure 1, one embodiment of the present invention includes a system 
100 for sharing data among a plurality of users. Included is a plurality of personal digital 
assistants (PDA's) 102, a server 104, a plurality of client computers 106 each removably 
connected to the PDA's 102, and a network 108 interconnected between the client computers 106 
and the server 104. 

The PDA's 102 may include a hand-held Palm™ PDA available from 3Com Corporation. 
In the alternative, the PDA's 102 may take the form of any other type of portable data storage 
module which is capable storing, editing, and/or synchronizing sets of personal data. This may 
be accomplished by any type of I/O mechanisms including, but not limited to a display, a 
plurality of push buttons, a data port, an electronic writing pad, and/or any other type of I/O 
mechanism capable of inputting and/or outputting personal data. 

In some embodiments, the personal data stored within the PDA's 102 may take the form 
of calendar information or contact information, i.e. mailing addresses, telephone numbers, 
facsimile numbers, electronic mail address, scheduled meeting, appointments, etc. In further 
embodiments, the personal data may include any useful task-oriented information. 

With continuing reference to Figure 1, the server 104 may include any data storage 
device located in any desired location. The server 104 may even take the form of a conventional 
computer. During use, the server 104 is capable of synchronizing sets of server data stored 
thereon with the personal data stored on the PDA's 102. This is carried out upon communication 
being established between the server 104 and the PDA's 102. 

Figure 2 shows one embodiment of the client computers 106 to which the PDA's 102 are 
releasably connected. As shown, each client computer 106 may include a microprocessor 1 10, 
read only memory 112, random access memory 1 14, a display 1 16, a data port 118, secondary 
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storage memory 1 20 such as a hard disk drive or a removable floppy disk drive, and/or a plurality 
of additional I/O peripherals 122. These components are connected by way of at least one bus 
124. 



5 In use, the client computers 106 are adapted for allowing communication between the 

server 104 and the PDA's 102 by providing a communication link therebetween. The coupling 
between the client computers 106 and the server 104 may, in one embodiment, include a local or 
wide area network. One example of a network 108 that may be employed for affording the 
foregoing coupling is the Internet or any other intranet. In other embodiments, other types of 
10 coupling may be employed including RF, fiber optic, or any type of transmission medium 
capable of transferring data and control signals. It should be understood that any of the 
foregoing types of coupling may also be employed for affording a link between the PDA's 102 
and the client computers 106. 

15 In one embodiment, the client computer 106 may be excluded in favor of incorporating 

the necessary components thereof into either the server 1 04, the PDA 1 02, or an unillustrated 
communication interface device. In such embodiment, the communication link between the 
server 1 04 and the PDA 1 02 may be either a hard-line or wireless. 



20 Figure 3 depicts the foregoing components interconnected according to one embodiment 

of the present invention. In order to allow communication between the PDA's 102 and the client 
computers 106 and server 104, a conduit manager 126 such as Hotsync Manager™ provided by 
3Com with Palm™ PDA's is run by each of the client computers 106. The conduit manager is 
adapted for allowing data on the PDA's 102 to be synchronized with data from other sources 

25 such as the server 104. 



To accomplish this, the conduit manager 126 includes a plurality of communication links, 
or conduits 128, as shown in Figure 3. The conduits 128 are capable of governing 
synchronization with various data sources and by various methods. For example, the conduits 
30 C2 & C3 may be provided by 3Com for interfacing a specific data source. Further, another one 
of the conduits CI may be used to implement the method of the present invention. It should be 
noted that the conduit manager 126 and the conduits 128 may be software implemented using the 
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microprocessor 1 10 of the associated client computer 106 and computer logic stored in memory. 
In the alternative, a hardware implementation may be employed. 



10 



Specifically, conduit CI of the present invention may be used to interface both the local 
memory of the associated client computer 106 and the server 104 in a manner to be set forth later 
in greater detail. Upon a connection being established between the client computer 106 and the 
server 104, synchronization is executed. If, however, it is impossible for such connection to be 
established, a local copy of the synchronization may be stored on the local memory of the client 
computer 106 to be synchronized with the server 104 at a later time. 



As mentioned earlier, the types of personal data that may be stored on the PDA 102 
include contact and calendar information. During synchronization, both the contact information 
and calendar information may be exchanged between different PDA's 102. For example, contact 
information may be updated on multiple different PDA's 102, calendar information of a plurality 
1 5 of PDA's 1 02 may be synchronized and conflicts may be addressed, and/or calendar information 
of a plurality of users may be stored and updated on each PDA 1 02. In the case wherein calendar 
information of a plurality of users is stored and updated on each PDA 102, a user may select 
which calendar information of others that is updated on his or her PDA 102. 

20 In order to allow the synchronization and sharing of information between the PDA's 1 02 

in accordance with the present invention, the personal data, server data, and local data each has 
three fields of information stored therewith. These fields include a name field, an identification 
field, and an index field. Located in the identification fields of the personal data of the PDA's 
102 are personal identification codes 138. Further, server identification codes 140 are located in 

25 the identification fields of the server data of the server 1 04. The personal identification codes 
138 are stored on either the PDA's 102, the server 104, or the client computer 106 in which the 
conduit 128 is resident for correlation purposes during synchronization. 

In a preferred embodiment, the personal identification codes 138 are stored on the 
30 associated client computer 1 06. In a more preferred embodiment, the personal identification 

codes 138 are stored on the server 104. Finally, the personal identification codes 138 are stored 
on the PDA's 102 in a most preferred embodiment. 
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Figure 3 shows the personal identification codes 138 to be correlated with the server 
identification codes 140 for keeping track of the correspondence between the personal data stored 
on the PDA's 102 and the server data stored on the server 104. This is especially critical during 
the synchronization of such data. 

Figure 4 illustrates one of the conduits 128 of the conduit manager 126 of Figure 3. In 
use, the conduit 128 of the present invention is adapted for establishing communication between 
the PDA's 1 02 and the server 104 to not only synchronize the data of a PDA 102 and a client 
computer 106, but also synchronize the personal data of different PDA's 102. 

To accomplish this, the conduit 128 includes a conduit controller 130 which is directly 
controlled by the conduit manager 126 and is suitable for interfacing the PDA's 102. The 
conduit 128 further includes a client messenger 132 in communication with the conduit 
controller 1 30 and suitable for interfacing the server 104. It should be noted that the client 
messenger 1 32 is further suitable for interfacing local memory of the associated client computer 
106 to synchronize local data stored thereon with the personal data and the server data. As 
mentioned earlier, this is particularly critical when a connection between the conduit controller 
130 and the server 104 is nonexistent at the time of synchronization. 

With continuing reference to Figure 4, it is shown that conduit memory 1 36 may be 
connected between the conduit controller 130 and the client messenger 132 for facilitating 
operation. Further, a conduit driver 134 may be included within the corresponding client 
computer 106 to act as an interface between the conduit 128 and the PDA's 102. Such conduit 
driver 134, in one embodiment, may take the form of a conduit SDK which is provided by 
3Ccom™ for Palm™ PDA's. 

With reference now to Figure 5, a flowchart is illustrated which delineates the procedure 
executed by one of the components of the present invention, namely the conduit controller 130 of 
the conduit 128 of Figure 4. Such procedure relates specifically to the operation of the conduit 
controller 1 30 during the synchronization of one particular type of personal data, the contact 
information. As shown in operation 500, the conduit controller 130 first opens the client 
messenger 132 after which a mapping file is read from the PDA 102 (in the most preferred 
embodiment) that is currently connected to the client computer 106 in an operation 502. Such 
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mapping file consists of the personal and server identification codes 140 and the correlation 
therebetween. 

With continuing reference to Figure 5, the mapping file is then synchronized with the 
5 client messenger 132, as indicated by operation 504. As mentioned earlier, the client messenger 
132 provides an interface with the server 104 and the local memory of the client computer 106. 
As such, when the conduit controller 130 synchronizes the mapping file with the client 
messenger 132, such synchronization actually occurs with respect to the identification codes 
within the server 104 and local memory. It should be noted that synchronization of the mapping 
1 0 file is critical so that personal data within the PDA's 1 02 is properly correlated with respect to 
the data within the server 104 and local memory. Only with proper correlation can the data be 
properly edited to conform during the synchronization process. 

Once the mapping file is synchronized, tables of categories are created by the conduit 
1 5 controller 1 30 in the conduit memory 1 36 in operation 506. Such categories include groups of 

data organized as a function of any of the fields associated with the data, i.e. name, identification, 
index, etc. Further, a table of categories is generated specifically for the data in the PDA 1 02, the 
local memory of the client computer 106, and the server 104. Since the client messenger 132 
interfaces the local memory and the server 104, the tables of categories associated with the local 
20 memory and the server 104 appear, from the perspective of the conduit controller 130, to be 

tables associated with the client messenger 132. After the tables of categories have been created 
in operation 506, the categories of the different tables are synchronized in that "dirty" categories 
from the PDA table and the client messenger table are adjusted to conform. Note operation 508. 

25 As shown in Figure 5, once the categories are synchronized, the data, or records, in the 

categories are synchronized by the conduit controller 1 30 along with the mapping file in 
operation 510. Next, in operation 512, the tables of synchronized categories and records, and the 
mapping file are written to the PDA 102 via the conduit controller 130 and further written to the 
local memory of the client computer and the server 104 via the client messenger 132. After the 

30 tables are written, the client messenger 1 32 is closed by the conduit controller 1 30. Note 
operation 514. 
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Figure 6 shows a more detailed flowchart corresponding to operation 500 in Figure 5. As 
shown, when the client messenger 132 is opened in operation 516, the conduit controller 130 
passes a user name and a server name in respective operations 518 and 520. It should be noted 
that the user name corresponds to the PDA 102 of a specific user and the server name 
5 corresponds to a server 104 on which the appropriate server data resides. 

With reference now to Figure 7, a more specific flowchart is provided that delineates the 
details regarding operation 506 in Figure 5. In operation 522 of Figure 7, the aforementioned 
tables are created by first receiving the categories via the client messenger 132. Accompanying 
1 0 the categories are the records which are also retrieved and added to the corresponding table in 
operations 524 and 526, respectively. This is repeated until each table has a complete listing of 
the categories and associated records, as indicated by decision 528. 

Figure 8 is a flowchart delineating in greater detail operation 508 of Figure 5 wherein the 
1 5 categories are synchronized. First, in operation 530, a back-up database that is resident in the 
local memory of the client computer 106 is read. Such back-up database may have been 
generated on the server 104 or client computer 106 after a previous synchronization. Next, the 
conduit controller 130 performs an operation 532 on each category of the table associated with 
the PDA 102. In particular, the conduit controller 130 marks each category of the PDA table that 
20 is "dirty" or, in other words, has been modified. 

With continuing reference to Figure 8, the conduit controller 130 next performs an 
operation 534 on each category of the table associated with the client messenger 132. 
Specifically, if the category of the client messenger table is deleted and exists on the PDA table, 
25 the corresponding records are marked as "changed" and the category is marked as "unfiled" after 
which the corresponding category on the PDA table is deleted. 

A subsequent operation, operation 536 of Figure 8, is performed on each category of the 
table associated with the PDA 102. During such operation, the conduit controller 130 renames 
30 categories of the client messenger table if the PDA category name is not marked as changed and 
a category by that name does not exist on the client messenger but a category with the same 
identification code does exist and that category is not marked as a new category from the client 
messenger. 
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Operation 538 of Figure 8 is subsequently carried out for each of the categories of the 
client messenger table. Operation 538 includes changing the PDA table to ensure that each 
category of the PDA table has one and only one corresponding category on the client messenger 
table. 

Yet another operation, operation 540, of Figure 8 is carried out for each of the categories 
of the client messenger table. Such operation 540 includes deleting a category on the client 
messenger table if a corresponding category can not be found on the PDA table. Operation 540 
of Figure 8 further has a component which is carried out for each category of the PDA table. 
Such component includes adding a category of the PDA table to the client messenger table if the 
name of the category of the PDA table does not have a match on the client messenger table. 
Finally, all of the categories of the client messenger table are deleted and read back. 

With reference now to Figure 9, a specific flowchart is provided illustrating the details 
associated with operation 538 shown in Figure 8. As mentioned earlier, operation 538 of Figure 
8 includes changing the PDA table to ensure that each category of the PDA table has one and 
only one corresponding category on the client messenger table. The flowchart of Figure 9 begins 
by retrieving each category of the client messenger table, as indicated in operation 542. Next, in 
decision 546, it is determined whether the name of a category on the PDA table matches that of a 
category on the client messenger table. 

If it turns out that a match is found in decision 546 in Figure 9, it is next determined 
whether the category on the client messenger table is new in decision 548. If it is, the category 
of the client messenger table is renamed and subsequently deleted. Note operation 550 of Figure 
9. If, however, the category on the client messenger table is not new, the category on the PDA 
table is changed to reflect the corresponding category of the client messenger table, as indicated 
in operation 552 of Figure 9. It should be noted that such operation 552 is executed only if the 
index of the category of the PDA table is not equal to that of the client messenger table and 
further the identification code of the category of the PDA table matches that of the client 
messenger table. 



12 



0062576A1J._> 



WO 00/62576 PCT/US00/09324 

Similar to decision 548 of Figure 9, if it turns out that a match is not found in decision 
546, it is next determined whether the category on the client messenger table is new in decision 
554. If it is, a new index and identification code is retrieved based on the PDA table in operation 
558 after which the category of the client messenger table is changed to reflect the new index 
5 and identification code. Also in operation 558, the category of the client messenger table is 
added to the PDA table. 

On the other hand, if the category on the client messenger table is determined not to be 
new in decision 554 of Figure 9, it is then determined in decision 556 whether the category of the 
10 PDA 102 has an identification code that matches that of the category of the client messenger 

table. It is also determined in decision 556 whether the name of the category of client messenger 
table has changed. 

If the answer to decision 556 of Figure 9 is "Yes", yet another decision, decision 560, is 
1 5 determined, namely whether the name of the category of the client messenger table has changed. 
If the answer to decision 560 is "Yes", the name of the category of the PDA 102 is changed 
accordingly in operation 564. If, however, the name of the category of the client messenger table 
has not changed and the answer to decision 560 is te No", the records of the category of the client 
messenger table are changed to those of the category of the PDA table after which the name of 
20 the category of the client messenger table is changed. See operation 562 of Figure 9. 

If the answer to decision 556 of Figure 9 is "No", yet another decision, decision 566, is 
determined, namely whether the name of the category of the client messenger table has changed. 
If the answer to decision 566 is "Yes", operation 558 is carried out in a manner already described 
25 hereinabove. If, however, the name of the category of the client messenger table has not changed 
and the answer to decision 560 is "No ", the records of the category of the client messenger table 
are changed to unfiled in operation 568. 

With reference now to Figure 10, a flowchart is illustrated which delineates another 
30 procedure executed by the conduit controller 130 of the conduit 128 of Figure 4. As opposed to 
the procedure delineated in Figure 5, the procedure shown in Figure 10 relates to the 
synchronization of a different type of data, namely the calendar information. In comparison to 
the flowchart of Figure 5, the present flowchart differs in the addition of a few operations. For 
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example, after the client messenger 132 is opened in operation 600, a calendar information file is 
read in operation 602 after which the calendar information file is synchronized in operation 604, 
Next, an association file is read and passed to the client messenger 132 in operation 606. 

5 With continuing reference to Figure 10, yet another additional operation, operation 608, 

follows the synchronization of the mapping file with the client messenger 132. In operation 608, 
the aforementioned association file is synchronized. Operations 610-616 are continued until 
each calendar is completed. Further, in addition to writing the mapping files, the association 
files are also written, as indicated in operation 618. It should be noted that each of the remaining 
10 operations delineated in Figure 10 are the same as the corresponding operations of Figure 5 as 
described in detail hereinabove with the exception of the type of data that is synchronized. 

Figure 1 1 illustrates the various server data that is stored on the server 1 04. Such data 
includes a plurality of record lists, or SyncRecordLists 700, that are communicated with the 

15 PDA's 102 via the conduit 128 of Figures 3 and 4. The record lists include information such as a 

type number, an identification number, a start version number, an end version number, etc. 
Further, the record lists contain records, or SyncRecords 702, each including a local 
identification code; a shared identification code identifying users with whom data is shared; flags 
to indicate new, deleted, and conflicted information; etc. In addition, each of the records 

20 includes any information that has changed since the last synchronization. 

With reference to Figure 12, a flowchart is provided which delineates the process 
associated with the server 104 of the present invention. As shown, the process begins with 
operation 800 wherein a specific record list, SyncRecordList, of records, or SyncRecords, is 

25 found or created in response to a query made by a conduit 128. A loop is then executed during 

which the records are retrieved in operation 802 and then monitored in decision 804 to determine 
whether records have changed since the last synchronization. If changes have occurred on the 
record, such record is added to the record list as indicated in operation 806. It should be noted 
that only changed information is included in the added record. The loop continues until all of the 

30 records have been checked for changes in decision 808. 

With continuing reference to Figure 12, the process associated with the server 104 
continues with operation 810 wherein a query record is retrieved. If the query record is resident 
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in a response list as indicated in decision 812, the record is marked as conflicted and is dealt with 
in operation 813. If, however, the query record is not in the response list, it is next determined 
what type of change has occurred in decision 814. 

5 If a "new" change has occurred, a new record is made and the version number of the 

record list is incremented. See operation 816 in Figure 12. It should be noted that this 
incremented version number is used as an identification code for the new record. If a "modified" 
change has occurred, a new record is added to the record list and the version number is 
incremented, as indicated in operation 818. Finally, operation 820 is carried out if a "delete" 
1 0 change has occurred. In such case, a new record is added to the record list, the version number is 
incremented, and the record is marked as deleted. The forgoing process is continued until no 
more records exist. Finally, the update is returned in operation 822. 

Up to now, the operation of the conduit controller 130 and the server 104 has been set 
1 5 forth. As mentioned earlier, the conduit controller 130 creates tables of categories and records 

and subsequently synchronizes such information. When carrying out such processes, the conduit 
controller 130 communicates with the server 104 (via the client messenger 132) by way of 
queries which are handled in a manner shown in Figures 7 and 8 regarding the server. Focus will 
now be given to the manner in which the client messenger 132 of the conduit 128 provides an 
20 interface between the conduit controller 130 and the server 104. 

Figure 13 is a specific flowchart illustrating the details associated with the operation of 
the client messenger 132 during one of the operations of the conduit controller 130 of the conduit 
128 shown in Figures 5 and 6, respectively. In particular, Figure 13 delineates, in detail, the 

25 process associated with the client messenger 1 32 during operations (504 & 5 1 0) and (606, 611, 
& 612) of the conduit controller 130 shown in Figures 5 and 6, respectively. First, it is 
determined whether the record list is open in decision 900. A local copy is read if the list is not 
open in operation 902. If the list is open, the process of Figure 13 is complete. Next, it is 
determined whether the record list is shared in 904. As indicated in operation 906, a 

30 synchronization is carried out with the server 1 04 if the list is shared. If the list is not shared, the 
process of Figure 13 is complete. 
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Similar to Figure 13, Figure 14 is a specific flowchart illustrating the details associated 
with the operation of the client messenger 132 during one of the operations of the conduit 
controller 130 of the conduit 128 shown in Figures 5 and 6, respectively. In particular, Figure 14 
delineates, in detail, the process associated with the client messenger 132 during operations 514 
5 and 620 of the conduit controller 130 shown in Figures 5 and 6, respectively. 

As shown in Figure 14, it is first determined whether the record list is open in decision 
1000. If the record list is not open, the process of Figure 14 is done. If the record list is indeed 
open, it is subsequently checked whether the record list is shared in decision 1002. If the record 

10 list is shared, a synchronization is carried out with the server 104 in operation 1004 after which a 
local copy is written in operation 1006. If the record list is not shared, only operation 1006 is 
carried out. It should be noted that the local copy generated in Figure 14 is critical in the case 
wherein a connection to the server 104 is non-existent. In such situation, the appropriate 
synchronization is carried out between the local copy and the server 104 once communication is 

15 established. 

With reference now to Figure 15, illustrated is a detailed process of the client messenger 
132 that is executed during operations 906 and 1004 of the client messenger 130 shown in 
Figures 9 and 10, respectively. The process of Figure 15 begins by determining whether a 

20 connection with the server 104 exists in decision 1 100. As mentioned earlier, such connection 

may be made by any means including the Internet. Once it is ascertained that a connection 
exists, a record list, or SyncRecordList, is started in a manner that will be set forth later in greater 
detail. See operation 1 102 of Figure 15. Once the record list is started, a loop begins with the 
retrieval of a next local record in operation 1004. As long as the record is not null as determined 

25 in decision 1 106, a determination is made whether the record represents a change from a 

previous synchronization in operation 1 108 and, if so, is added to the record list in operation 
1110. 

As shown in Figure 15, if it is determined that the current record is null in decision 1 106, 
30 the query is sent to the server 104 in operation 1112 after which the client messenger 132 waits 
for an update in operation 1114. Finally, a process update in operation 1 1 1 6 is carried out in a 
manner to be set forth later in greater detail. 
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In Figure 16, a detailed flowchart is shown illustrating one of the operations of the client 
messenger 132 shown in Figure 15, namely the process update in operation 1116. As shown, the 
process update operation begins by getting a next update record in operation 1200. If the record 
type is not null as determined by decision 1202, a number of operations may take place 
5 depending on the type of record retrieve. 

For example, if the decision 1204 of Figure 16 determines that the record is new, the 
record is added to a local list. Note operation 1206. If, however, the record is changed, a local 
copy of the record is changed in operation 1208. In operations 1210 and 1212, the local copy of 
10 the record is marked as removable and current, respectively. Finally, if the record is conflicted, it 
is added to a conflict list in operation 1214. By marking the various records in the foregoing 
manner, the appropriate action may be taken by the server 1 04 during synchronization. 

With continuing reference to Figure 16, the illustrated process is continued upon the 
15 update record being determined to be null by decision 1202. Once it has been determined that 
the conflict list is not empty by decision 1216, it then determined in decision 1218 what type of 
conflict policy governs the way in which the conflicted records are managed. It should be noted 
that a conflict occurs when particular personal data of a first one of the PDA's 102 is 
synchronized with the server data before the particular personal data of a second one of the 
20 PDA's 102 is synchronized with the server data, and the particular personal data of the first and 
second PDA's 102 are marked to be shared. 

As shown in Figure 16, with a replicate policy, the conflict is resolved by replicating the 
particular personal data in operation 1220 after which a synchronization is carried out with the 

25 server 104, as indicated by operation 1222. With a PDA override policy, the conflict is resolved 
by synchronizing the conflicted personal data of the PDA 102 with the server data. Similar to 
the previous policy, a synchronization is executed with the server 104, as indicated by operation 
1224. With a server override policy, the conflict is resolved by not synchronizing the conflicted 
personal data of the PDA 102 with the server data. Finally, the conflict is resolved by marking 

30 the conflicted personal data of the PDA 102 for allowing a user to later rectify the conflict via a 
user interface, as indicated in operation 1226. This last policy is referred to as a marking policy. 
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The specific processes related to each of the foregoing policies of dealing with conflicted 
data will now be set forth with specific reference to Figures 17-19. As shown in Figure 17, the 
marking policy begins by getting a next conflicted record and adding the same to a local record 
list marked as conflicted. Note operations 1300 and 1302. This is continued until there are no 
5 more remaining conflicted records. With reference to Figure 1 8, the replicate policy is 

delineated wherein once a next conflicted record is retrieved which is not null, it is determined 
whether the conflicted record is marked as being deleted or modified in decision 1304. If 
modified, a new local record is added. See operation 1306. 

10 In Figure 19, the override policy of Figure 16 is delineated. After retrieving a next 

conflicted record which is not null in operation 1308, it is determined whether the conflicted 
record is a deleted or modified record in decision 1310. If the conflicted record is modified, the 
local record is modified to match the conflicted record in operation 1312. If, however, the 
conflicted record is deleted, the local record is marked as deleted as indicated by operation 1314. 

15 

While various embodiments have been described above, it should be understood that they 
have been presented by way of example only, arid not limitation. Thus, the breadth and scope of 
a preferred embodiment should not be limited by any of the above described exemplary 
embodiments, but should be defined only in accordance with the following claims and their 
20 equivalents. 
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CLAIMS 

What is claimed is: 

1 . A system for sharing data among a plurality of users via an intermittently accessed 
network comprising: 

5 a plurality of portable data storage modules each suitable for storing a plurality of 

personal data sets thereon; 

a server including server data sets stored thereon; and 

a plurality of client computers for providing a communication link between the portable 
data storage modules and the server, each communication link suitable for synchronizing server 
10 data sets stored thereon with the personal data sets stored on the portable data storage modules 
for obtaining the personal data set of one portable data storage module on another portable data 
storage module, thereby synchronizing the personal data sets between different portable data 
storage modules; 

said communication link suitable for interfacing local memory of the corresponding client 
1 5 computer to synchronize a plurality of local data sets stored thereon with the personal data sets 

during synchronization in the absence of communication between the communication link and 
the server. 

2. The system as recited in claim 1, wherein the personal data sets include task-oriented 
information. 

20 3. The system as recited in claim 2, wherein the personal data sets include at least one of 
contact and calendar information. 

4. The system as recited in claim 1, wherein the communication link is connected to the 
server via the network. 

5. The system as recited in claim 4, wherein the network is at least one of the Internet and 
25 an intranet. 
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6. The system as recited in claim 1, wherein the communication link includes a link 
controller suitable for interfacing the portable data storage modules, and a client messenger in 
communication with the link controller and suitable for interfacing the server and the local 
memory. 



5 7. The system as recited in claim 1, wherein the communication link synchronizes the local 

data sets on the local memory with the server data sets on the server upon communication being 
established between the communication link and the server. 

8. The system as recited in claim 1 , wherein the personal data sets and the server data sets 
each has three fields of information stored therewith including a name field, an identification 

10 field, and an index field for facilitating synchronization. 

9. The system as recited in claim 1, wherein the personal data sets of each of the portable 
data storage modules has personal identification codes and the server data sets of the server has 
server identification codes, wherein a map correlating between the personal identification codes 
and the server identification codes is stored on at least one of the portable data storage module, 

15 the server, and a computer in which the communication link is resident for identification 

purposes during synchronization of the personal data sets and the server data sets. 

10. The system as recited in claim 9, wherein the map is stored on the portable data storage 
modules. 

1 1 . The system as recited in claim 9, wherein the synchronization of the personal data sets of 
20 different portable data storage modules only occurs on personal data sets specifically marked to 

be shared by including the server identification codes of the personal data sets of other portable 
data storage modules. 

12. The system as recited in claim 1, wherein the synchronization of the personal data sets 
between different portable data storage modules only occurs on personal data sets specifically 

25 marked to be shared. 
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13. The system as recited in claim 12, wherein a conflict occurs when a particular personal 
data set of a first one of the portable data storage modules is synchronized with the server data 
set before the particular personal data set of a second one of the portable data storage modules is 
synchronized with the server data set, and the particular personal data sets of the first and second 

5 portable data storage modules are marked to be shared. 

14. The system as recited in claim 13, wherein the conflict is resolved by replicating the 
particular personal data set. 

15. The system as recited in claim 13, wherein the conflict is resolved by synchronizing the 
particular personal data set of the second portable data storage module with the server data set. 

10 16. The system as recited in claim 13, wherein the conflict is resolved by not synchronizing 
the particular personal data set of the second portable data storage module with the server data 
set. 

17. The system as recited in claim 13, wherein the conflict is resolved by marking the 
particular personal data set of the second portable data storage module and alerting a user of the 

1 5 conflict via a user interface. 

18. A method for sharing data among a plurality of users via an intermittently accessed 
network comprising the operations of: 

storing a plurality of personal data sets on a plurality of portable data storage modules; 
establishing a communication link between the portable data storage modules and a 

20 server; 

obtaining the personal data set of one portable data storage module on another portable 
data storage module by synchronizing the personal data sets with a plurality of server data sets 
stored on the server; and 

interfacing local memory to synchronize a plurality of local data sets stored thereon with 
25 the personal data sets during synchronization in the absence of communication between the 
communication link and the server. 
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19. The method as recited in claim 18, wherein the personal data sets include task-oriented 
information. 



20. The method as recited in claim 19, wherein the personal data sets include at least one of 
contact and calendar information. 

5 21 . The method as recited in claim 1 8, wherein the communication link is resident in a client 

computer and is connected to the server via the network. 

22. The method as recited in claim 21, wherein the network is at least one of the Internet and 
an intranet. 

23. The method as recited in claim 18, wherein the communication link includes a link 
10 controller suitable for interfacing the portable data storage modules, and a client messenger in 

communication with the link controller and suitable for interfacing the server and the local 
memory. 

24. The method as recited in claim 1 8, further comprising the operation of synchronizing the 
local data sets on the local memory with the server data sets on the server upon communication 

1 5 being established between the communication link and the server. 

25. The method as recited in claim 18, wherein the personal data sets and the server data sets 
each has three fields of information stored therewith including a name field, an identification 
field, and an index field for facilitating synchronization. 

26. The method as recited in claim 1 8, wherein the personal data sets of each of the portable 
20 data storage modules has personal identification codes and the server data sets of the server has 

server identification codes, wherein a map correlating between the personal identification codes 
and the server identification codes is stored on at least one of the portable data storage module, 
the server, and a computer in which the communication link is resident for identification 
purposes during synchronization of the personal data sets and the server data sets. 
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27. The method as recited in claim 26, wherein the map is stored on the portable data storage 
modules. 



28. The method as recited in claim 26, wherein the synchronization of the personal data sets of 
different portable data storage modules only occurs on personal data sets specifically marked to 
be shared by including the server identification codes of the personal data sets of other portable 
data storage modules. 

29. The method as recited in claim 1 8, wherein the synchronization of the personal data sets 
between different portable data storage modules only occurs on personal data sets specifically 
marked to be shared. 

30. The method as recited in claim 29, wherein a conflict occurs when a particular personal 
data set of a first one of the portable data storage modules is synchronized with the server data 
set before the particular personal data set of a second one of the portable data storage modules is 
synchronized with the server data set, and the particular personal data sets of the first and second 
portable data storage modules are marked to be shared. 

3 1 . The method as recited in claim 30, wherein the conflict is resolved by replicating the 
particular personal data set. 

32. The method as recited in claim 30, wherein the conflict is resolved by synchronizing the 
particular personal data set of the second portable data storage module with the server data set. 

33. The method as recited in claim 30, wherein the conflict is resolved by not synchronizing 
the particular personal data set of the second portable data storage module with the server data 
set. 

34. The method as recited in claim 30, wherein the conflict is resolved by marking the 
particular personal data set of the second portable data storage module and alerting a user of the 
conflict via a user interface. 
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35. A computer program embodied on a computer readable medium for providing a 
communication link between a server and a portable data storage module which is capable of 
sharing data among a plurality of users via an intermittently accessed network comprising: 

a code segment for synchronizing at least one personal data set on a portable data storage 
5 module with at least one server data set on a server in order to share the personal data set on the 
portable data storage module with another portable data storage module; and 

a code segment for interfacing local memory to synchronize at least one local data set 
stored thereon with the personal data set during synchronization in the absence of 
communication between the communication link and the server. 

10 36. The computer program as recited in claim 35, wherein the personal data sets include task- 
oriented information. 

37. The computer program as recited in claim 36, wherein the personal data sets include at 
least one of contact and calendar information. 

38. The computer program as recited in claim 35, wherein the communication link is resident 
15 in a client computer and is connected to the server via the network. 

39. The computer program as recited in claim 38, wherein the network is at least one of the 
Internet and an intranet. 

40. The computer program as recited in claim 35, wherein the communication link includes a 
link controller suitable for interfacing the portable data storage modules, and a client messenger 

20 in communication with the link controller and suitable for interfacing the server and the local 
memory. 

41 . The computer program as recited in claim 40, further comprising a code segment for 
synchronizing the local data sets on the local memory with the server data sets on the server upon 
communication being established between the communication link and the server. 
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42. The computer program as recited in claim 35, wherein the personal data sets and the 
server data sets each has three fields of information stored therewith including a name field, an 
identification field, and an index field for facilitating synchronization. 

43. The computer program as recited in claim 35, wherein the personal data sets of each of 

5 the portable data storage modules has personal identification codes and the server data sets of the 
server has server identification codes, wherein a map correlating between the personal 
identification codes and the server identification codes is stored on at least one of the portable 
data storage module, the server, and a computer in which the communication link is resident for 
identification purposes during synchronization of the personal data sets and the server data sets. 

10 44. The computer program as recited in claim 43, wherein the map is stored on the portable 
data storage modules. 

45. The computer program as recited in claim 43, wherein the synchronization of the personal 
data sets of different portable data storage modules only occurs on personal data sets specifically 
marked to be shared by including the server identification codes of the personal data sets of other 

15 portable data storage modules. 

46. The computer program as recited in claim 35, wherein the synchronization of the personal 
data sets between different portable data storage modules only occurs on personal data sets 
specifically marked to be shared. 

47. The computer program as recited in claim 46, wherein a conflict occurs when a particular 
20 personal data set of a first one of the portable data storage modules is synchronized with the 

server data set before the particular personal data set of a second one of the portable data storage 
modules is synchronized with the server data set, and the particular personal data sets of the first 
and second portable data storage modules are marked to be shared. 

48. The computer program as recited in claim 47, wherein the conflict is resolved by 
25 replicating the particular personal data set. 
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49. The computer program as recited in claim 47, wherein the conflict is resolved by 
synchronizing the particular personal data set of the second portable data storage module with the 
server data set. 

50. The computer program as recited in claim 47, wherein the conflict is resolved by not 

5 synchronizing the particular personal data set of the second portable data storage module with the 
server data set. 

51. The computer program as recited in claim 47, wherein the conflict is resolved by marking 
the particular personal data set of the second portable data storage module and alerting a user of 
the conflict via a user interface. 
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